Remarks 



The various parts of the Office Action (and other matters, if any) are discussed 
below under appropriate headings. 

Drawings 

The drawings have been objected to allegedly for not showing every feature of 
the invention specified in the claims. According to the Examiner, the drawings fail to 
show various "steps" recited in the claims. 

The requirement to show each claimed feature does not apply to the "steps" of 
method or process claims. Drawings generally are not necessary for the understanding 
of the steps recited in a method claim, and certainly this is true in the present case. 
The steps recited in the instant method claims are adequately described in the 
specification and no depiction thereof is seen necessary for the understanding of the 
steps set forth in the claims. 

Therefore, withdrawal of the requirement that the drawings show the "steps" 
recited in the claims is respectfully requested. 

The drawings also are objected to because multiple parts allegedly are not 
labeled with reference numerals. According to the Examiner, Figures 2-5 show a 
number of constituent parts in the PACS element 30 that are not labeled. To the 
contrary, various labels are applied to various areas within the PACS element 30, such 
as C, V, M1-M4, etc., and these labels are utilized in the specification. The addition of 
another set of reference characters identifying the same elements would be superfluous 
and do nothing more than clutter the drawings and specification. As for Figure 6, 
various labels are used to denote elements shown in the figure. The undersigned is not 
aware of any requirement that these labels be numbers as opposed to letters. 

Therefore, withdrawal of the further objections to the drawings is respectfully 
requested. 

Specification 

The specification has been objected to because of an alleged uncertainty as to 
what is meant by "DR" and "CR". As known to those skilled in the art, "DR" stands for 
"digital radiography" and "CR" stands for "computed radiography." In the context of a 
description of medical imaging modalities integrated with a PACS network, as on page 
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10 of the specification, the skilled person would readily understand these common 
acronyms accordingly. 

Claim Rejections - 35 U.S.C. § 112 

Claims 1-13 have been rejected as being indefinite. 

Regarding the meaning of "model-view-controller", such term is a well-known 
term in the art, as it has been in use for several decades. As evidence, a brief search 
on the Internet produces many web pages both using and describing the term. See, for 
example, the entry in Wikipedia. 

Model-view-controller (MVC) is an architectural pattern used in software 
engineering. Successful use of the pattern isolates business logic from 
user interface considerations, resulting in an application where it is easier 
to modify either the visual appearance of the application or the underlying 
business rules without affecting the other. In MVC, the Model represents 
the information (the data) of the application and the business rules used 
to manipulate the data, the View corresponds to elements of the user 
interface such as text, checkbox items, and so forth, and the Controller 
manages details involving the communication to the model of user actions 
such as keystrokes and mouse movements. 

Regarding the term "glue bridge" such term in used in the context of a software 
bridge or software glue, i.e. a software component designed to facilitate communication 
between two other software components - software that joins or "glues" the 
components together to bridge communication between them. In the context of the 
present application, the glue bridge allows communication between the software 
component and the PACS network, so that the software component may be generic yet 
still communicate with different PACS networks. See the description on page 18, and 
Figure 4. 

The term "non-standard" in claim 8 is intended to express the fact that different 
PACS providers tend to implement PACS networks differently. Thus, a PACS network 
will have "standard" aspects which are common to PACS networks in general, and 
"non-standard" aspects which are specific to the particular provider or even the 
particular network. The presence of non-standard aspects can mean that software 
applications and components, if provided in a generic form, cannot communicate with 
every PACS network. Therefore, to allow integration into any PACS network, a glue 
bridge software component is provided to allow integration of the claimed visualization 
application and software component (claims 1 and 6) into a PACS network, where the 
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glue bridge accommodates any non-standard aspects. See page 18 of the description, 
and page 7, lines 12-18. 

Regarding the term "operable", the Examiner's contention of indefiniteness is 
traversed. Nevertheless, the term has been replaced with "configured" throughout the 
claims so as to render the issue moot. 

In addition, claim 5 has been amended to resolve any issue respecting 
antecedent basis. 

In view of the foregoing, withdrawal of the claim rejections under 35 U.S.C. § 112 
is respectfully requested. 

Claim Rejections - 35 U.S.C. § 101 

Regarding the rejections under 35 U.S.C. § 101, claim 1 has been amended into 
a format more acceptable to U.S. practice. As amended, claim 1 recites "A software 
component containing a medical-imaging visualization application, the software 
component comprising computer executable instructions embodied on a computer 
readable medium that are configured when executed...." The rejection of claims 1-5 
under 35 U.S.C. § 101 should now be withdrawn. 

Regarding claim 6, exception is taken to the contention that the recited subject 
matter is nonstatutory. Nevertheless, claim 6 has been amended to recite "A PACS 
network including a logic device for executing instructions of a The rejection of 
claims 6-13 under 35 U.S.C. § 101 should now be withdrawn. 

35 U.S.C. § 103 

The claims have been rejected as being unpatentable over US 5,875,327 (herein 
"Brandt") in view of US 6,574,629 (herein "Cooke"). The Examiner's remarks in support 
of the rejection have been carefully considered, but the rejections are submitted as 
being improper for at least the following reasons. 

According to the Examiner, the features of the independent claims are all found 
in Brandt except the network being a PACS network and the application being a 
medical imaging visualization network. The Examiner says these latter features can be 
found in Cooke. After careful review of Brandt, the Examiner appears to be mistaken 
and the independent claims recite other features not found in Brandt. This will become 
apparent from the following discussion. 
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Applicant describes in his specification a software product and methodology that 
addresses the problem of how to integrate a computer application program such as a 
medical imaging visualization application into a PACS network. Typically such 
applications are provided by a variety of providers and hence each may have a different 
user interface. These give a non-uniform appearance to the overall network, and also 
require network users to be familiar with many different interfaces. To address this, 
PACS network providers may prefer to import only the functionality of the applications, 
and supplement this with their preferred unitary user interface. This is typically 
achieved by licensing granular versions of applications. This approach has many 
difficulties, as explained on pages 3 and 4 of applicant's specification. 

To address this, applicant proposes that a visualization application be provided 
within a software component, where the software component is a model component for 
use in a model-view-controller architecture. A model component, by definition, provides 
the fundamental functional aspects of an application. By also providing the software 
component with an interface having appropriate parameters, the application contained 
in the software component can be integrated into a PACS network. The parameters 
are selected to allow this integration. The software component comprises the model 
component, whereas the view component and the controller component can be located 
within the PACS network, and built by the PACS provider so as to give the application 
the provider's preferred user interface. Thus, the PACS provider obtains the 
functionality of the application, and can integrate it into his network with the desired look 
of user interface without having to understand the fundamental operation of the 
application's functionality, because this is contained within the model component, and 
the view and controller components can be implemented independently of the contents 
of the model component by use of the parameters of the interface. See page 5, lines 
12-25 of the specification for these and other advantages that are attainable. 

Independent claim 1 is directed to a software component containing a 
visualization application, where the software component is a model component, and 
has an interface with parameters for allowing integration into a PACS network. Brandt 
has not been found to describe any such software component. 

Brandt describes an arrangement for configuring workstations on a network. A 
plurality of servers are connected to a network, and the network also includes a server. 
A plurality of preference files are stored on the server with a server preference 
manager. The preference files indicate configuration preferences for configuring 
hardware and software according to the preferences of individual users, groups of 
users, workstations, manufacturers, system administrators, etc. When a user logs onto 



Page 8 of 11 



a workstation on the network, the preference manager recognizes the user and 
retrieves the relevant preference files. The preferences are coalesced to a preference 
set, which is downloaded to the workstation. The workstation then configures itself 
according to the preference set, and thereby has the configuration according to the 
preferences of that user (including any group he belongs to, his administrator, etc.). 

Presumably, the Examiner is equating the preference files of Brandt with the 
software component of claim 1 . However, the preference files do not contain a 
medical-imaging visualization application (or indeed any application) as required by 
claim 1 . The preference files merely express preferences for configuration parameters 
such as screen color, mouse operation, and the like. Also, Brandt has not been found 
to include any mention whatsoever of a model-view-controller software architecture, 
and nothing described in Brandt appears to have the features of a 
model-view-controller software architecture. Hence, the preference files in Brandt are 
not seen as being operable, or configured, to function as a model component in a 
model-view-controller software architecture. 

Furthermore, the preference files of Brandt do not have an interface having a set 
of user interface control parameters and a set of data handling parameters, as required 
by the software component of claim 1 . The preference files are not described as having 
any kind of interface, which is unsurprising since they are merely files which record 
preferred values for configuration parameters, and do not need to interface with 
anything. Use of the term "parameter" in Brandt refers to parameters for configuring 
the hardware and the software, and as best understood not to any interface parameters 
of the type recited in claim 1 . Therefore, the preference files in Brandt do not have an 
interface having parameters selected for integration of an application into a network 
(PACS or otherwise). The preference files in Brandt are not in any way similar to the 
software component of claim 1, and are not intended for use in integrating applications 
into networks. 

The addition of Cooke does not overcome the fundamental deficiencies of 
Brandt as a teaching reference vis-a-vis claim 1. While Cooke does describe a PACS 
network with applications for visualizing medical images, a combination of Brandt and 
Cooke does not result in the subject matter of claim 1 . Any reasonable combination of 
Brandt and Cooke at most would give a PACS network including a server storing 
preference files such that a workstation would be configured according to the 
preferences of a user logging onto that workstation, in the manner of the network in 
Brandt. 
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Independent claim 6 is directed to a PACS network including a software 
component having all the features of claim 1 . Therefore, claim 6 is also not obvious 
with regard to Brandt in combination with Cooke, for at least the same reasons as claim 
1. 

Regarding independent claim 14, the Examiner appears to be equating "a first 
version of the application contained in a high-level software component" and "a second 
version of the application contained in a lower-level software component" with 
preference files at different levels of the hierarchical arrangement of preference files 
described in Brandt. This is incorrect for several reasons. 

Firstly, the preference files in Brandt are, as mentioned above, merely files 
storing preferred values of configuration parameters. They are not software 
components containing applications, in particular not software components containing 
data visualization applications. 

Secondly, the "levels" in Brandt (column 9, line 9-14, referenced by the 
Examiner) refer to the levels in the hierarchical arrangement of the preference files, 
where administrator preferences are ranked higher than user preferences, for example. 
In contrast, the terms "high-level software" and "lower-level software" in claim 14 take 
their usual conventional meaning. There is nothing in the claim or the description to 
indicate any other interpretation. "Level" in the context of software refers to its position 
within the functionality of the computer system, with low level referring to programming 
and processing dealing with the very fundamental inner operation of the computer (and 
therefore more readily transferable between computer systems) and high level referring 
to the operations and interactions experienced by and evident to the user (and 
therefore more specific to an individual system or application). Clearly, these are very 
different from the hierarchical levels described in Brandt, and Cooke offers little if 
anything in this context. 

The remaining claims are dependent claims, so are not obvious for at least the 
reasons discussed above. The absence of any specific comment regarding the 
Examiner's contentions relating to the dependent claims should not be viewed as an 
acquiescence therein. Rather, no comment is needed since the rejections are deficient 
at least for the reasons discussed above with respect to the independent claims. 

Conclusion 

In view of the foregoing, request is made for timely issuance of a notice of 
allowance. 
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Respectfully submitted, 

RENNER, OTTO, BOISSELLE & SKLAR, LLP 



/Don W. Bulson/ 

By 

Don W. Bulson, Reg. No. 28,192 

1621 Euclid Avenue 
Nineteenth Floor 
Cleveland, Ohio 44115 
(216) 621-1113 
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